Incidents were resolved by restoring data to the active path and correcting access so the affected accounts could see their files. For AD-rename cases file-services moved user data from the old folder into the corrected new folder and adjusted NTFS/SMB permissions so the renamed account regained access. Where home shares had been decommissioned, users were informed that H: had been retired; the team identified target SharePoint/Teams sites or OneDrive locations and confirmed whether content had been migrated, restored missing items from on-prem backups or migration exports when those sources contained the files, and notified users when content was permanently absent and offered recovery or re-upload options. For remote/VPN cases where automatic mapping was not present, a manual network mapping to the user’s home share was created and connectivity over VPN was verified. For legacy SFirm digital-signature access, SFirm server folders were created and users’ key files were copied from the old share into C:\Digitale Bankingsignaturen\USERNAME with folder permissions restricted to the respective user. For new Windows 11 devices the service clarified that H: was not provisioned by default and OneDrive was the intended primary location for personal files. In one decommissioning inquiry affecting a finance Excel macro that required a local H:, the reporting user later documented a workaround and the ticket was closed without support action; no technical remediation steps were recorded in that ticket.

Access issues were resolved by addressing three distinct causes found across incidents. 1) AD group membership and CIFS permissions: users were added to the specific AD groups that granted CIFS/SMB access (for example CifsAccess_CPG_Buchhaltung or equivalent departmental groups). Once memberships propagated and the user re-authenticated on the corporate network (or rebooted with VPN credentials available at logon), the network drives auto-mapped. Propagation delays of a few hours were observed in some cases. 2) Logon context and VPN pre-logon: several failures were traced to mappings created in a different authentication context than the user’s interactive session. Drives that required the VPN at Windows startup only mounted when the VPN connection and credentials were present during logon; mappings initiated after login often failed. Additionally, some Windows 11 devices were not domain-joined and lacked legacy pre-logon VPN/network-drive support, preventing direct CIFS/DFS access on those machines; these devices required alternate access paths or migration targets. 3) Provisioning and migrations: some drives were not governed solely by AD groups but required explicit provisioning by administrators or automation (the DEVdrive was provisioned by an admin and the system mapped the drive automatically, showing a disclaimer popup). In several cases teams also confirmed that content had been migrated to OneDrive/SharePoint (or was in the process of migration), so missing folders sometimes reflected migration or data-placement changes rather than permission issues. Resolutions therefore included granting the correct CIFS access groups, provisioning drives where required, confirming whether content had been migrated to SharePoint/OneDrive (and handling data-recovery if needed), and ensuring the mapping was created in the same authentication/VPN context used at logon.

Planned migrations were paused while ownership and access were re-evaluated for affected departmental SMB/CIFS shares. Investigations found active password-manager databases on Marketing shares (KeePass .kdbx and 1Password storage), which prevented immediate bulk migration of those shares. Where primary data had already been moved to SharePoint, teams inspected remaining legacy files (notably old freelancer contracts) and verified retention requirements. The Finance archive (formerly on J:) was migrated into SharePoint under '12_Archiv Finance' and users were notified of the new location. Some marketing shares were left unchanged pending owner identification and access decisions. An SMB share with unusually complex ACLs (used as interim/temporary storage by two exam-office staff on Windows 11 devices) was not migrated; an alternative storage arrangement was provided for those users and stakeholders were informed. A separate access issue was logged for the BHF-Examination-Planning share (\cpgazu1fs5.cpg.int\cpggroupfs\BHF-Examination-Planning, ~41.8 GB) where members of the AD group CifsAccess_examination-planning reported the share as read-only; that ticket was closed as Done and contained an automation-suggested remediation but recorded no detailed execution steps. Overall, migrations were completed where ownership and sensitivity were clarified (finance archive, moved content), and shares with unclear ownership, complex ACLs, or active sensitive vault files were retained pending owner identification or targeted remediation.

The NAS was confirmed to be powered off, an onsite contractor was engaged to power the QNAP device back on, and the network share became available via hostname or IP once the device was online. The user reconnected to the share using either \libfqnap or \\10.0.0.6 and regained access to the Moodle backup files.

Access was restored by granting the requester’s account explicit file‑share permissions on the file server. When available, support used an existing reference user who already had correct access (for example to the IUBH‑Rectorate or Distribution folders) to determine and replicate the required permission set before assigning it to the requester; similar explicit permission grants resolved access to an accounting drive after a team transfer. Requests were routed to a specialist team when the shared‑folder path was not provided; in several cases no technical fix was implemented because the user did not supply the folder address and the ticket was closed automatically after the retention period.

IT re-triggered the repository/folder synchronization process. After re-running the sync, the five previously missing student submission folders became visible to the professor.

A dedicated NFS backup store was provisioned for Catalyst Center. WLC backup jobs were configured to run via Catalyst Center so that WLC backups were executed through Catalyst Center and stored on the newly provided NFS backup location.

An Azure Files SMB share (//iugteaqshare.file.core.windows.net/iugteaqshare) was provisioned and mounted on the application servers at /var/www/iugteaqshare. Instead of exposing SMB to external networks, automated transfers and vendor exchanges were mediated by the application (SiteFusion scheduled jobs/cronjobs) running on internal hosts that had the SMB mount. Mount permissions and Linux mount options were adjusted to provide read/write/execute and allow subfolders, and the Azure storage allocation was sized to accommodate the estimated package volume. This approach delivered a mounted network share for the application and automated jobs while keeping SMB access inside the corporate network.